My script source will stay set to Inline source code. With the parameters sorted, I switch to the Step tab. It comes in handy when debugging and testing the step. Print Command?: I added this parameter to use set -x to print the command when it runs. Only Targets: Only deploy to specified, comma-separated targets (e.g., hosting,storage).Įxcept Targets: Deploy to all targets except specified (e.g. Message: An optional message describing this deploy.įorce?: Delete Cloud Functions missing from the current working directory without confirmation. Public Path: Override the Hosting public directory specified in firebase.json. Sensitive parameter values will be encrypted in the database and masked in the logs. I make this parameter a sensitive parameter. The rest of the parameters will follow a similar naming convention and will only differ by type.įirebase Path: The path to the directory containing the Firebase CLI, if not in $PATH.ĬI Token: A CI token is required for Octopus to use the Firebase CI on my behalf. I set the help text to “The package containing the Firebase project being deployed.” I give it the label and control type Package. A prefix for the parameters will prevent name collisions with other Octopus variables. I name my package parameter FirebaseDeploy.Package. When adding a parameter, I provide a name, label, help text, and the control type. A package parameter lets consumers of my step, provide a package for the step to use. Package parameters are a relatively new feature in Octopus Deploy. I add a parameter for the package containing my Firebase assets. Then I start working on the step details and add newly discovered parameters as I go.įor this post, I describe all of the parameters before I move into the step details. I usually start with the parameters that I know I will need. Should I add parameters to my step next, or should I add the step details and logic? I take advantage of this to link back to the Firebase CLI docs: ![]() Seeing the logo for the technology related to the tech provides a little flair for the step.įinally, I give the step a description. The logo isn’t required, but I like to add them. Since I am wrapping the Firebase deploy command, I called my step Firebase Deploy. Here I can provide a name, logo, and description.Ĭhoosing a good, descriptive step name is vital. Octopus launches me into the Settings tab. ![]() I click Add on the Run a Script template, and that takes me to the step template editor. The Run a Script step is well-suited for this. The machine that the command runs on is not important. I only need to run the Firebase CLI against my files. ![]() That is not the case for my Firebase deployment. The Deploy a Package step is for deploying the contents of a package to the machine or PaaS target where it will run. I am deploying the contents of a package to Firebase, so Deploy a Package looks like a reasonable choice. The first decision I need to make is which of the existing step templates I am going to build on. Let’s get started! Choosing a base template I host some projects on Firebase, so I have chosen to create a template for the Firebase CLI deploy command. They can also standardize actions across your projects. Today, I am going to create a custom step template in Octopus Deploy.Ĭustom step templates are useful for extending the functionality of Octopus.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |