Task 3.3: Distribute and maintain actions

• APick a name that no GitHub user, organization or listing already uses

  Correct

  A listing's name can't match a GitHub user or organization unless that owner publishes it.

• BKeep the name and publish from an organization she owns

  Incorrect

  Only the acme-deploy organization's owner can publish under that name.

• CKeep the name and move action.yml into a subfolder named acme-deploy instead

  Incorrect

  The name rule applies to the listing whatever folder the metadata is in.

• DKeep the name and ask GitHub Marketplace to review it manually

  Incorrect

  Actions that meet the requirements are published without review, and the name rule still applies.

Actions that meet GitHub Marketplace's requirements are published immediately, without review. One requirement is a unique name: it can't match an existing Marketplace action, a GitHub user or organization (unless that owner publishes it), a Marketplace category, or a reserved GitHub feature name.

• ATurn immutable releases off during each release run and back on afterwards

  Incorrect

  Every release made while the setting is off loses the protection that immutable releases give users.

• BKeep deleting and re-creating the v2 release at each new version

  Incorrect

  Once v2 is an immutable release, deleting it lets the tag be deleted, but the tag name v2 can't be reused.

• CTell users to switch from @v2 to the newest full version on every release

  Incorrect

  That puts the work on every user instead of keeping v2 current.

• DCreate GitHub releases only for full versions such as v2.3.1, and keep v2 as a plain Git tag that the workflow force-pushes

  Correct

  Tags not tied to a release can still be moved, while each full version stays immutable.

An immutable release locks its Git tag and assets: the tag can't be moved, and if the release is deleted the tag can be deleted but its name can't be reused. GitHub's guidance for actions with immutable releases is to create releases only for versions that must never change, such as v1.0.0, and to keep major or minor version tags that should move as plain Git tags not tied to a release, updating them with a force push.

• ARead the REST endpoint from the GITHUB_API_URL environment variable

  Correct

  GITHUB_API_URL points at the REST API of the platform the workflow runs on.

• BPublish a separate Marketplace listing for each GitHub platform

  Incorrect

  One listing serves every platform once the action stops hard-coding URLs.

• CRead the GraphQL endpoint from GITHUB_SERVER_URL

  Incorrect

  GraphQL calls use GITHUB_GRAPHQL_URL; GITHUB_SERVER_URL is the web address.

• DUse the @actions/github toolkit package, which sets the right URLs

  Correct

  The toolkit sets the correct API URLs automatically.

• EAdd an api-host input whose default is the REST endpoint https://api.github.com

  Incorrect

  The default would still send customers to api.github.com unless each one overrides it.

Many people use GitHub at a domain other than GitHub.com, such as GHE.com or a GitHub Enterprise Server host. To stay compatible, an action shouldn't hard-code API URLs such as https://api.github.com. Use the GITHUB_API_URL variable for the REST API and GITHUB_GRAPHQL_URL for GraphQL, or a toolkit such as @actions/github that sets them.

• AIt must be public

  Correct

  Sharing an action with everyone requires a public repository.

• BIt must belong to an organization

  Incorrect

  Personal accounts can share public actions too.

• CIt must be listed in GitHub Marketplace

  Incorrect

  Public actions can be used without a Marketplace listing.

• DIt must contain a workflow file

  Incorrect

  An action needs metadata and code, not a workflow.

To share actions with everyone, the repository must be public. Public actions can be used by workflows in any repository, whether or not they are listed in GitHub Marketplace.

• AThe listing keeps the verified creator badge

  Incorrect

  The badge follows the creator, so it doesn't stay after the transfer.

• BThe badge stays until the next release is published

  Incorrect

  The badge is lost with the transfer itself.

• CThe badge moves to the new organization's profile

  Incorrect

  The profile Verified badge is a different thing from the Marketplace badge.

• DThe listing loses the verified creator badge

  Correct

  After a transfer, the badge remains only if the new owner is also a verified creator.

The verified creator badge on GitHub Marketplace marks creators that GitHub has verified as partner organizations, and it differs from the Verified badge on an organization's profile. If an action repository is transferred, the listing loses the badge unless the new owner is also a verified creator.

• ADevelop and validate the release on a release branch, such as release/v1

  Correct

  GitHub's tag-based process starts with developing and validating the release on a release branch.

• BMove the major version tag v1 to the new commit

  Incorrect

  The major version tag is moved only after the release has been created.

• CCreate the release with the semantic version tag v1.0.1

  Incorrect

  The release is created once the release branch has been validated.

• DPublish the release to GitHub Marketplace

  Incorrect

  Publishing to Marketplace is optional and happens when a release is created, after validation.

In GitHub's tag-based release management for actions, maintainers develop and validate a release on a release branch (for example, release/v1), create a release with a semantic version tag (for example, v1.0.1), and then move the major version tag (for example, v1) to the Git ref of that release.

• AA price plan for the action

  Incorrect

  Actions are published without paid plans.

• BThree tags that describe the action

  Incorrect

  The form asks for categories and a version tag, not descriptive tags.

• CA primary category, with an optional second one

  Correct

  The primary category is chosen from a dropdown, and another category can be added.

• DA reviewer from GitHub's partner team to approve the listing

  Incorrect

  Actions that meet the requirements are published without review.

When drafting a release with Publish this Action to the GitHub Marketplace selected, you choose a primary category, optionally another category, and a version tag, then publish the release.