Skip to content

More CI related stuff#739

Open
StaticRocket wants to merge 6 commits into
TexasInstruments:masterfrom
StaticRocket:master
Open

More CI related stuff#739
StaticRocket wants to merge 6 commits into
TexasInstruments:masterfrom
StaticRocket:master

Conversation

@StaticRocket

Copy link
Copy Markdown
Member

Good news. Hopefully this can be a reference for how to use workflows somewhat correctly now. All issues I can find have been addressed. Bad news is, vale might cause us some issues when the next dependabot update comes around. We'll deal with that later. Need to get it back up and running for now.

  • ci: use !cancelled() instead of always()

    Apparently you can ignore a cancel request with the always() function. This is
    only documented on a single page in the GitHub workflow docs that I found in
    passing checking other garbage.

    I assume this means you could also bypass concurrency flags with this in
    place. Don't really want to find out.

    Signed-off-by: Randolph Sapp rs@ti.com

  • ci(vale): work around vale-action issue

    Work around an upstream issue [1] with a manual pin for now. Hopefully this
    won't break future dependabot checks.

    [1] Release named v2.1.2 points to tag named 2.1.2 vale-cli/vale-action#158

    Signed-off-by: Randolph Sapp rs@ti.com

  • ci: pin all workflows

    It's generally advised to pin workflow versions to avoid issues with floating
    tags or manipulated releases. Dependabot can still track and upgrade things if
    we add inline comments.

    Signed-off-by: Randolph Sapp rs@ti.com

  • ci: yamllint disable max line length check

    Well, version pinning requires inline comments that frequently make lines go
    over the recommended 80 character length. Disable this check for all the
    workflow files preemptively.

    Signed-off-by: Randolph Sapp rs@ti.com

  • ci(build): merge the docker and build workflow

    As much as I liked the simplicity in the old workflow definition, it had
    issues when pushing container updates in combination with source updates. The
    docker and build workflows would race.

    Needs explicit checks for "!failure() && !cancelled()" because once one thing
    in a needs chain is unsatisfied (or skipped) GitHub would prefere to
    invalidate the entire chain.

    Signed-off-by: Randolph Sapp rs@ti.com

  • ci(vale): restrict paths

    We can avoid running this entirely if none of the files we're looking for have
    been modified. I wish we could use a yaml anchor or something to prevent
    duplicating the patterns here, but it doesn't seem like that's an option as
    the other workflow only wants strings.

    Signed-off-by: Randolph Sapp rs@ti.com

We can avoid running this entirely if none of the files we're looking
for have been modified. I wish we could use a yaml anchor or something
to prevent duplicating the patterns here, but it doesn't seem like
that's an option as the other workflow only wants strings.

Signed-off-by: Randolph Sapp <rs@ti.com>
As much as I liked the simplicity in the old workflow definition, it had
issues when pushing container updates in combination with source
updates. The docker and build workflows would race.

Needs explicit checks for "!failure() && !cancelled()" because once one
thing in a needs chain is unsatisfied (or skipped) GitHub would prefere
to invalidate the entire chain.

Signed-off-by: Randolph Sapp <rs@ti.com>
Well, version pinning requires inline comments that frequently make
lines go over the recommended 80 character length. Disable this check
for all the workflow files preemptively.

Signed-off-by: Randolph Sapp <rs@ti.com>
It's generally advised to pin workflow versions to avoid issues with
floating tags or manipulated releases. Dependabot can still track and
upgrade things if we add inline comments.

Signed-off-by: Randolph Sapp <rs@ti.com>
Work around an upstream issue [1] with a manual pin for now. Hopefully
this won't break future dependabot checks.

[1] vale-cli/vale-action#158

Signed-off-by: Randolph Sapp <rs@ti.com>
Apparently you can ignore a cancel request with the always() function.
This is only documented on a single page in the GitHub workflow docs
that I found in passing checking other garbage.

I assume this means you could also bypass concurrency flags with this in
place. Don't really want to find out.

Signed-off-by: Randolph Sapp <rs@ti.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant